\documentclass{article}

%\usepackage[latin1]{inputenc}

% \usepackage[latin1]{inputenc}
% \usepackage[brazil]{babel}
%\usepackage[T1]{fontenc}		% fontes PS com acentos
\usepackage[brazil]{babel}	
\usepackage[utf8]{inputenc}
% \usepackage{amsmath}
% \usepackage{amsfonts}
% \usepackage{amssymb}

\title{Answers for the questions about the thesis' manuscript}
\author{Plácido A. Souza Neto}
%\date{\today} 
 

 
% \def\ie{\textit{i.e.}} 
% \def\eg{\textit{e.g. }}
% \def\wrt{\textit{wrt }}
% \def\A{\hbox{${\cal A}$}}    
% \def\C{\hbox{${\cal C}$}}
% \def\O{\hbox{${\cal O}$}}
% \def\D{\hbox{${\cal D}$}}
% \def\F{\hbox{${\cal F}$}}

\begin{document}
 
\maketitle 


\section{Context}
\label{sec:context}

\subsection{Questions}


 \begin{quotation}\sf\footnotesize
\noindent
10 - Na frase a seguir n\~ao fica claro como MDA alinha os conceitos de RNFs e
SOC: ``MDA [67] is an important approach for the alignment between highlevel
information modelling, non-functional requirements\ldots''. Na pr\'atica, \'e
preciso explicar porque o uso de MDA favorece/ajuda o tratamento de RNFs.
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
22 - N\~ao tenho certeza, mas acredito que alguns elementos dos metamodelos da
$\pi$SOD-M j\'a tenham sido definidos na SOD-M. Seria interessante, se isto est\'a
acontecendo, destacar estes elementos para deixar claro ao leitor os elementos
que s\~ao exclusivos da $\pi$SOD-M.    
\end{quotation}
 

\begin{quotation}\sf\footnotesize
\noindent
23 - Observando a Figura 4, \'e poss\'ivel observar que $\pi$SOD-M tem as mesmas
etapas de SOD-M, mas com foco no RNFs. Isto sugere (posso estar enganado) que toda a
parte ``funcional'' foi aproveitada na SOD-M. Isto \'e verdade?   
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
30 - N\~ao est\'a muito clara (justificada) a necessidade de um ``Process Model'' e
um ``Composition Model''. Observe que em nota\c c\~oes como WS-BPEL os elementos destes
dois modelos est\~ao de certa forma juntos, ou seja, talvez seja interessante
justificar porque a metodologia adota esta separa\c c\~ao.    
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
34 - Observe que processos em WS-BPEL possuem muito mais do que ``sequence of
activities'' (ver frase ``It can be visualized with a flowchart as a sequence of
activities with interleaving decision points''). Na pr\'atica, por tr\'as desta
minha observa\c c\~ao est\'a a constata\c c\~ao de que o modelo para defini\c c\~ao de processos proposto ( PI-ServiceProcess) \'e muito mais simples do aqueles apresentados em
nota\c c\~oes como URN e WS-BPEL (usadas com o mesmo objetivo e que j\'a possui
metamodelos).    
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
35 - Quem \'e o ``Application designer''? Qual o perfil? \'e algu\'em de neg\'ocio ou de
TI? Isto \'e importante estar definido na metodologia, pois provavelmente existem
v\'arios atores (business expert, qos expert, TI expert) envolvidos nas v\'arias
etapas da metodologia. Por exemplo, algu\'em de neg\'ocio seria capaz de definir uma
express\~ao como estas apresentadas na Figura 20 (e.g., $\#$bankBlance $>$
paymentValue \&\& \ldots ). Veja ainda na p\'agina 85: quem \'e o
``designer'' referido na frase ``The designer must specify\ldots''.      
\end{quotation}


\subsection{Discussion}

MDD is an important approach for aligning information about abstract modeling
levels and non-functional requirements. In model-based development, the
information will be refined at each level through model transformation,
thereby the NFRs can be best described their concepts and needs in the
application development.

MDD has beed increasingly employed to guide development with focus on the
generation of code from models. The modeling aspects of non-functional
properties remains difficult. Models that describe non-functional properties may be used
to express, in the specification phase, transversal characteristics of the
application.  As the specification of these models is done , essential
properties are being incremented \cite{Rottger04}.

The challenge to the use of MDD in modeling of cross-cutting aspects of the
application from the more abstract level of design is the ability to use
different types of models for different purposes and understand the differences
between the terminologies for the non-functional properties
\cite{LimingZhu2009}.

$\pi$SOD-M considers these concepts to cover the non-funcional aspects and
service-oriented standards for a MDA based development. $\pi$SOD-M inherits all
the functional part from SOD-M, and includes the elements necessary to model
non-functional aspecs in terms of \textsc{Policy}.

The modeling of business process proposed in $\pi$SOD-M is simpler than
those seen in the WS-BPEL. In addition we use two models to express: (i) the
main workflow, and (ii) the relationship of each activity with external services.


The main objective of having two models to describe the service process 
($\pi$-ServiceProcess and $\pi$-ServiceComposition)  is to have a clear
separation of concepts to be modeled at each stage of development. While the
($\pi$-ServiceProcess model describes the business process model, the
$\pi$-ServiceComposition model describes the services needed for its execution.
Although WS-BPEL defines a similar set of concepts, our goal was
also to simplify the description of these process.


 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

  
\section{Problem Statement and Hypothesis}
\label{sec:problem_hypothesis}

\subsection{Questions}

\begin{quotation}\sf\footnotesize
\noindent
2 - Senti falta de justificativas de porque a proposta foi desenvolvida apenas
para Web services. Observe que existem diversos servi\c cos que n\~ao s\~ao Web,
ou seja, n\~ao s\~ao descritos em WSDL, n\~ao s\~ao armazenados em UDDIs e usam outros
protocolos de comunica\c c\~ao diferentes de SOAP.   
\end{quotation} 


\begin{quotation}\sf\footnotesize
\noindent
7 - N\~ao h\'a uma discuss\~ao de porque tratar RNF \'e dif\'icil ou porque SOC
facilita o tratamento destes requisitos.
\end{quotation}
 

 
\begin{quotation}\sf\footnotesize
\noindent
8 - Por que Web services e n\~ao Servi\c cos foram considerados? Por que o trabalho
considera apenas Web services? Existe uma raz\~ao particular para isto, uma vez
que torna a solu\c c\~ao restrita ao universo de Web Services?  
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
12 - Rever ou explicar a frase a seguir: ``The design addresses the functional
requirements while architecture provides the non-functional requirements like
scalability, reliability and performance are realized.'' Esta frase sugere que o
projeto (design) trata os requsitos funcionais enquanto a arquitetura trata os
RNFs. Na pr\'atica, no entanto uma diferen\c ca b\'asica destes requisitos n\~ao \'e a etapa de desenvolvimento em que eles s\~ao tratados, mas o fato de que normalmente
os requisitos funcionais est\~ao confinados (ou s\~ao implementados) em elementos
pontuais da implementa\c c\~ao. Por sua vez, os RNFs s\~ao pervasivos, ou seja, est\~ao
normalmente espalhados em toda a implementa\c c\~ao. Por exemplo, para ser seguro,
todas as partes do sistema precisam ser seguras.       
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
18 - Senti falta tamb\'em de uma discuss\~ao sobre ``correla\c c\~ao'', ``conflitos'' e
``prioridade'' entre RNFs. Estes dois aspectos s\~ao muito discutidos quando
fala-se em RNFs.   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
21 - Uma das RQs poderia ser ``metodologias fazem o desenvolvimento de
composi\c c\~oes por orquestra\c c\~ao ou por coreografia?'' Isto mereceria tamb\'em uma
discuss\~ao na tese, pois s\~ao as estrat\'egias normalmente usadas na computa\c c\~ao
orientada a servi\c cos. Ainda relacionado a isto, outro ponto que deveria ter sido
discutido na tese \'e o fato de que metodologias para este tipo de desenvolvimento
tem como etapas principais a ``sele\c c\~ao'' e a ``combina\c c\~ao'' de servi\c cos. Compare
estas etapas com as etapas tradicionais.       
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
27 - Senti falta de uma descri\c c\~ao precisa do que sejam NF-Attributes,
NF-Properties e NF-Requirements. 
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
28 - N\~ao entendi a frase ``The quality properties at the system level represent
a behaviour that is part of the workflow.''
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
32 - N\~ao h\'a uma explica\c c\~ao sobre (i) porque a metodologia foi estruturada em
tr\^es vis\~oes (Business, System and Policy) e (ii) como chegou-se a estas tr\^es
vis\~oes.  
\end{quotation} 

\begin{quotation}\sf\footnotesize
\noindent
37 - Seria interessante justificar porque a linguagem PEWS foi escolhida para a
implementa\c c\~ao. Isto remete a outro importante, a metodologia \'e desacoplada desta
linguagem, ou seja, ela suportaria a gera\c c\~ao de composi\c c\~oes execut\'aveis em
WS-BPEL?   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
39 - J\'a existia um metamodelo de PEWS?   
\end{quotation} 

\subsection{Discussion} 

Even with the growing interest in developing higher-level models and design
paradigms, current technology is inadequate both representationally for
expressing such global constraints as formal non-functional requirements (NFRs)
and methodologically for utilizing them \cite{Chung91,MylopoulosBook99}. NFRs
specify global constraints that must be satisfied by the software \cite{RosaC04}. However, this
kind of requirements are not implemented such as functional requirements. 

While non-functional requirements express global constraints, non-functional
attributes (NFAs) model non-fuctional characteristics that can be precisely
measured , such as \textit{performance} \cite{RosaC04}. This kind of characteristics are
closer to implementation. An NFA describes the quality or characteristics of a
functional requirement.

A NFR is a group of semantically correlated nonfunctional
attributes (NFA). For example, \textit{security} is an NFR that
comprises attributes such as \textit{confidentiality} and \textit{integrity}.
The concept of non-functional property brings together all kinds of
software's constraint. Thus, it can be used as a synonym for NFRs or NFAs.


Ensuring non-functional properties is a challenge to develop
general applications, especially distributed applications that rely on
network resources, or where services are performed. However, as services are
independent components and has a finer granularity, to ensure that services
constraints are satisfied is a bit easier. As each service provides access to
its interface, its clients have an opportunity to check if the result satisfies
or not, even during the execution of the application. Moreover, the guarantee of
non-functional properties in service composition is not as trivial to solve.
This occurs because of non-functional requirements, in most cases, have
distributive characteristics, or even opposite. For example, to provide
security, all services of the composition should be safe. To ensure satisfactory
response time, all services of the composition must provide the results obeying
restrictions of the client.  

Due to these problems, non-functional properties are treated in services
in a particular way, for example, most studies attempt to ensure
specific requirements in the modeling of service-oriented applications.
Knowing this problem, we try to cover with $\pi$SOD-M a slightly
more general and abstract approach based on contracts for services. Contracts
for services can be specified for both services simple or compound.

The treatment we give to compound services are that if there is a conflict in
relation to contracts, the contract is broken and the composition is not suitable for the application. As our approach is based on contracts for services, the guarantee of non-functional
properties is directly related to the verification of contracts, inputs and
outputs required for a service, or a composition of services. In $\pi$SOD-M, a
set of contracts are grouped a Policy. Therewith, we defined the Policy view
concepts to model the constraints for service-oriented applications. The Business and Service views were inherited
from SOD-M \cite{CastroMV11}, while the Policy concepts were designed to cover
the elements and concepts necessary for describing constraints for services. The
Business view defines the the elements to model the business process, while the
Service view defines the elements necessary for design the service-oriented
structure \cite{CastroMV11}. Thus, the original structure SOD-M was extended to
cover a way to represent the non-functional properties during the project design.

As the $\pi$SOD-M methodology is actually decoupled from any language, it is
possible to generate code for $\pi$-PEWS, WS-BPEL, XAML and other languages for
describe business/service process. It is necessary define the meta-model and then
specify the mapping rules (transformations between the models). The  $\pi$-PEWS
language was chosen for be the implementation environment for $\pi$SOD-M because
we have been working with this language throughout the our research group. We
develop the $\pi$-PEWS meta-model, based on the $\pi$-PEWS sintaxe, and then the
mapping rules between PIM and PSM were defined.

Likewise, the proposed methodology ($\pi$SOD-M) can be applied to any service
approach, not necessarily Web services. $\pi$-PEWS specifications
can have diferent types of namespaces, not only WSDL. It is possible to use the
methodology even if the used approaches are JSON, REST, Java RMI, WCF, and so
on. As contracts are about functions, the restrictions described  through the
contracts can used for any approach, not only Web services.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\section{Principles and Approach}
\label{sec:principles}

\subsection{Questions}


\begin{quotation}\sf\footnotesize
\noindent
11 - Observe na frase a seguir que WSDL e WS-BPEL n\~ao s\~ao ``plataformas de
servi\c co'': ``MDA allows the specification of a system as an abstract model,
which may be realized as a concrete implementation (program) for a particular service
platform (e.g. WSDL, BPEL or PEWS).''    
\end{quotation}

\begin{quotation}\sf\footnotesize 
\noindent
13 - Sugiro que tamb\'em seja discutido na tese o seguinte ponto: associar RNFs a
``composi\c c\~oes de servi\c cos'' ou a ``servi\c cos'' pode ser muito
dif\'icil, pois alguns RNFs s\~ao ``distributivos''. Imagine que o
desenvolvedor define que a composi\c c\~ao (e.g., formada por 5 servi\c cos) \'e segura. Isto implica (mesmo que n\~ao seja dito
pelo desenvolvedor) que todos os servi\c cos precisam ser seguros e que todas as
comunica\c c\~oes entre ele s\~ao seguras. Mas, imagine que um dos servi\c cos
n\~ao \'e seguro. Como esta situa\c c\~ao \'e tratada pela metodologia? Quais os artefatos
gerados no final?      
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
24 - DEVISE \'e uma metodologia?  
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
25 - N\~ao \'e muito claro como um ``requisito n\~ao-funcional'' pode ser representado
por um ``use case''.
\end{quotation}

  

\begin{quotation}\sf\footnotesize
\noindent
26 - Talvez esteja claro no texto, mas n\~ao ficou claro para mim os mapeamentos
``Constraint'' -> Contract e Contract-> Policy s\~ao realizados.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
29 - Observar esta parte ``$\pi$SOD-M is a MDA (Model Driven Architecture) based
methodology. It provides a framework for building service compositions
considering their non-functional requirements.'' A metodologia fornece um
framework? Os conceitos de metodologia e framework s\~ao muito distintos.   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
31 - Senti falta de uma descri\c c\~ao passo-a-passo da Figura 5, por exemplo,
``Inicialmente tem-se uma especifica\c c\~ao de um processo de neg\'ocio que \'e
transformado em um UseCase model...'' Esta explica\c c\~ao at\'e existe, mas est\'a
dilu\'ida nas p\'aginas subsequentes do texto quando voc\^e diz ``After modelling the
system services and feature...'' (pp. 62). Como esta figura \'e muito importante,
ela deveria ser bem descrita.      
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
33 - Sugiro uma explica\c c\~ao sobre o mapeamento apresentado na Figura 16. Por
exemplo, \'e preciso justificar porque uma ``Business Service'' \'e representado em
UML por um ester\'otipo.  
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
41 - Senti falta dos requisitos do ambiente de desenvolvimento proposto. Veja
que a Figura 41 j\'a mostra a arquitetura. Quais os requisitos que geraram esta arquitetura?
\end{quotation}

 
\begin{quotation}\sf\footnotesize  
\noindent
42 - O ambiente n\~ao deveria ser estruturado em ``vis\~oes'' como a metodologia?
\end{quotation}
 
\subsection{Discussion}

MDA (Model Driven Architecture) allows the specification of a system as an
abstract model, which may be realized as a concrete implementation (program).
Thus, MDA be typically used in developing service-oriented applications
\cite{AchilleosKP11,CastroMV11,DamascenoLMSSAMRSL11,KaterosKTV08,DAmbrogio06},
and generate code for a particular service description or specification languages,
for exemple, WSDL, WS-BPEL or $\pi$-PEWS.

There are other approaches for service-oriented development (that not
necessaraly usess MDA) such as the DEVISE methodology \cite{DEVISE}, which although not be a
development methodology, it is a methodology for defining infrastructure Web
services. Or even the S-Cube \cite{scube2010book} proposal. 
 
Our approach ($\pi$SOD-M methodology) provides a model-driven structure that
encompasses concepts related with service-oriented development and
non-functional properties. The method provides a set of concepts, steps and
transformations to develop the applications. $\pi$SOD-M provides an development
environment in the context of \textit{Eclipse Modelling}, built as a set of
plugins. The plugins are: \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
$\pi$-SerciveComposition} and \textit{$\pi$-PEWS}, beyond the transformation
plugins. Once the environment is proposed in context of the Eclipse, the
environmental requirements are the same as required by the Eclipse tool. 

The $\pi$-SOD-M development process follows a set of transformation and
editing models (presented in the Figure 5 of the thesis). From the requirements
and business specification documents \cite{scube2010book}, the $\pi$-UseCase
model is build. Based on this model, a sequence of transformations is performed
in order to better refine the concepts. From the $\pi$-UseCase model, which
represents the use cases, requirements and constraints of the application, the
$\pi$-ServiceProcess model is generated.

The $\pi$-ServiceProcess model describes the business process to be executed,
and their restrictions. From this model, the $\pi$-ServiceComposition model
is generated. This model is similar to the previous one. However it describes
which external services are related to each action/operation in the business
process. From the $\pi$-ServiceComposition model it is possible to generate a
specification for any linguage for describing services composition.

In $\pi$SOD-M, a \textsc{Use Case} can be related with a set of
\textsc{Constraints} (in $\pi$-UseCase Model). In specifying the $\pi$-UseCase
model, \textsc{Constraints} are always associated with a \textsc{Use Case}. As this model is a higher-level modeling,
each constraint is associated with a type of non-functional requirement
(candidate). During the transformations, this service restriction is being
refined in order to have accurate description to describe the desired
non-functional requirement. The \textsc{Constraints} are grouped into
\textsc{Contracts}, where the \textsc{Constraints} of the same use case are
transformed into \textsc{Assertions}, and these \textsc{Assertions} compose a \textsc{Contract} (in $\pi$-ServiceProcess Model). Finally, 
\textsc{Contracts} with common non-functional property (eg,
security) are grouped into a \textsc{Policy} (in $\pi$-ServiceComposition
Model).



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Background}
\label{sec:backgroud}

\subsection{Questions}

\begin{quotation}\sf\footnotesize
\noindent
1 - Qual a no\c c\~ao de ``confiabilidade'' usada no trabalho? Apesar de constar
no t\'itulo (``A methodology for building reliable service-based applications'') e
em v\'arias partes do documento, a metodologia proposta e os meta-modelos n\~ao
apresentam nenhuma caracter\'istica que sugira o desenvolvimento de aplica\c
c\~oes deste tipo. Na pr\'atica, a proposta da tese aparenta ter sido concebida
para o desenvolvimento de aplica\c c\~oes orientadas a servi\c cos em geral.      
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
3 - Al\'em da necessidade de remo\c c\~ao do termo ``reliable'' no t\'itulo,
sugiro que o t\'itulo da tese tamb\'em deveria considerar o fato de que
aplica\c c\~oes que tem servi\c cos como elementos de primeira classe s\~ao
referidas na literatura como ``service-oriented applications'' e n\~ao
``service-based applications''. N\~ao sei se houve uma discuss\~ao sobre isto,
mas esta diferen\c ca \'e significativa.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
4 - \'E preciso explicar no texto o que \'e uma aplica\c c\~ao orientada a
servi\c co confi\'avel, ou seja, qual a no\c c\~ao de ``confiabilidade''
adotada. Observe que ``confiabilidade'' tamb\'em \'e um RNF. Caracterizar bem a
confiabilidade destas aplica\c c\~oes ajudaria a entender como a metodologia
trata as particularidades deste requisito n\~ao funcional. Neste ponto, vale a
pergunta: e se as aplica\c c\~oes precisassem ser ``seguras'' (outro requisito
n\~ao funcional), a metodologia poderia ser tamb\'em aplicada?      
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
9 - Verificar a frase ``\ldots some proposals extend WSDL adding behavioral
characteristics, such as PEWS[27], BPEL4WS\ldots'' Observe que BPEL4WS n\~ao \'e uma
extens\~ao de WSDL. WSDL \'e uma nota\c c\~ao para defini\c c\~ao de interface de servi\c cos e
WS-BPEL \'e uma notao para composi\c cao de servi\c cos, ou seja, s\~ao nota\c c\~oes
com prop\'ositos muito distintos. Considere reescrever esta frase.    
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
20 - Esclarecer o que s\~ao Business Services. Este termo n\~ao \'e comum na \'area de servi\c cos. 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
36 - Que linguagens s\~ao estas ``behavioural web service interface languages''?    
\end{quotation}

\subsection{Discussion}

Bertrand Meyer presents in \cite{Meyer92,Meyer97} how to reduce bugs by building
software components on the basis of carefully designed contracts. Inspired on the notion
of reliability described in this works (``Reliability is even more important
in object-oriented programming than elsewhere.''), a software component, whether
a service or not, which is designed based on contracts has reduced the amount of
bugs, becoming more reliable. In the specific case of services, which are
loosely coupled components, the specification and verification of these
contracts must be performed by the services’ orchestrator, who shall verify the
validity and execution of these contracts.  

The concept of reliability used in the thesis, is the concept presented by Bertrand 
Meyer \cite{Meyer92,MeyerN93,Meyer97} in his definition of \textit{Design by
Contract}. Meyer \cite{Meyer97} gives these definitions, about
\textit{Correctness, Robustness} and \textit{Reliability}:
 
\begin{itemize}
  \item Correctness: The ability of software products to perform their exact tasks, 
as defined by their specification;
   \item Robustness: The ability of software systems to react appropriately to 
   abnormal conditions.
   \item Reliability: A concern encompassing correctness and robustness. As the
   contracts for service interfaces are designed to ensure the expected result
   after the task performed by the service, and that if the contract is broken,
   the service does not apply to the application, we try to ensure the
   correctness by applying contracts in independent services.
\end{itemize}

Likewise with the robustness, after a contract is broken, the specification 
describes alternative paths for the user does not notice the error. Thus, we can
say that the use of design by contract for services in service-oriented
applications can ensure the reliability of these kind of applications.     


Some proposals specify services and its compositions by adding
behavioral characteristics, such as $\pi$-PEWS \cite{Placido2010LTPD}, or even
WS-BPEL \cite{ws-bpel2}. $\pi$-PEWS is a behavioral language for web service
because describe not only the input/output interface of a web service but also the expected behaviour of its components. The extension of PEWS (for the generation of $\pi$-PEWS) was 
inspired by languages like JCML \cite{CostaMMN12}, JML \cite{LeavensKP07} and
Eiffel \cite{Meyer92b}, which describe contract to specify the behavior of a
function. Thus, in $\pi$-PEWS this behaviour can be specified by defining the
order the services will be executed (in the business process) and its
input/output restrictions.
 
In $\pi$SOD-M the concept of \textit{Business services} represents services
that are part of a business process. BPMN \cite{bpmn} defines a similar
term called \textit{Service operation} which is an operation that
is part of the business process. In services, a business service is represented by a service
(or a service composition) that will run in the business process.    

Considering the topics related with service-oriented development and
non-functional requirement, and even the contribution/discussion given about
these topics, we decided to change the thesis' title for: ``\textit{A
Methodology for Building Service-Oriented Application in the Presence of
Non-Functional Properties}''.

 
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\section{Validation}
\label{sec:validation}

\subsection{Question}


\begin{quotation}\sf\footnotesize
\noindent
5 - Deveria haver uma discuss\~ao na tese sobre a consist\^encia dos modelos.     
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
6 - Por que n\~ao foi feita nenhuma valida\c c\~ao ``quantitativa'' para mostrar quanto
a metodologia proposta ``facilita o desenvolvimento de aplica\c c\~oes
orientadas a servi\c co'' (ver defini\c c\~ao de valida\c c\~ao na pp. 116)? N\~ao h\'a evid\^encias de que a
metodologia facilita o desenvolvimento de aplica\c c\~oes orientadas a servi\c co.
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
43 - Ao inv\'es de ``estudos de caso'' colocaria ``Examples''. Removeria o Estudo
de Caso 1, pois ele foi usado em toda a tese e todos os principais elementos j\'a
foram apresentados no Cap\'itulo 3 (inclusive as figuras s\~ao as mesmas). 
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
44 - N\~ao fica claro o que \'e a ``an\'alise qualitativa'' mencionada.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
45 - Explicar melhor os trabalhos futuros. Evite itemiz\'a-los.
\end{quotation}
  
\subsection{Discussion}

While MDA uses a object-oriented modeling
language  (\textit{i.e.}, UML) as the core technology, it does not insists on
the importance of precise, formal  and automated  transformations model for the
design and implementation of the mappings  PIMs-to-PSMs rules, or PSMs to code.
MDA does not provide mechanisms to verify the consistency of the models
developed. However, there are some studies that focused on check
consistency of these models using a formal approach \cite{Varro04,PaigeV12}.

The verification of syntactic consistency of the models is performed by
the some MDA tools, such as the \textit{Eclipse Modeling}. As there was the
initial focus of our work verify the semantics of the models and of the
generated code (in order to analyze its consistency), we did not present in the
thesis' manuscript a discussion on this subject. However, we have identified as
future work (pg. 146) the need for formalize the transformation rules proposed
by $\pi$SOD-M.
 
We have the intention to perform a quantitative analysis for the final version
of the thesis' manuscript. We intend to perform an analysis of the code generated
in $\pi$-PEWS. Since the methodology generates the specification
of the application, describing the workflow and contracts, we will make a
comparison with a similar approach \cite{Milanovic2006} that considers some kind of
specification language, such as the method B. 
 
Considering Chapter 5, we will use the term ``\textbf{\textit{Examples}}'' for
the case studies presented. Similarly, instead of ``\textit{Validation}'' term,
we will use the term ``\textbf{\textit{Evaluation}}'', in Chapter 5, as a
way to better represent what was done. And, considering Chapter 6, we will
detail each future work instead of itemises them.
 
  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  
  
\section{Related Works and Comparison}
\label{sec:relatedWorks}

\subsection{Questions}


\begin{quotation}\sf\footnotesize
\noindent
14 - Senti falta de cita\c c\~oes a trabalhos de John Mylopoulos, cujo livro e
artigos s\~ao os mais importantes na \'area de RNFs. Em particular, o livro
``Non-Functional Requirements in Software Engineering'' \'e uma esp\'ecie de
``bíblia'' da \'area. Al\'em desta, existe uma vasta literatura sobre RNFs n\~ao
mencionada no texto: KAOS, i-star, NFR, URN/GRL (padr\~ao da ITU-T). A quase totalidade dos
elementos presentes nos metamodelos propostos j\'a constam nos trabalhos
mencionados acima, e.g., NF-Attribute, NF-Requirement, NF-Action, NF-Properties.
Inclusive, j\'a existem tamb\'em metamodelos e UML profiles para modelagem de RNFs. 


Por fim, tamb\'em senti falta de men\c c\~ao aos padr\~oes WS-* que se
relacionam a RNFs: WS-Policy, WS-SecurityPolicy, WS-Reliability, WS-Transaction,
e ``Quality Model for Web Services''.
\end{quotation}  

\begin{quotation}\sf\footnotesize
\noindent
19 - Observe que o trabalho de D'Ambrogio [34] tamb\'em tem MDA, RNFs e servi\c cos,
ou seja, ele deveria estar na mesma \'area que a proposta da tese na Figura 3. 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
38 - Por que as pol\'iticas n\~ao s\~ao descritas em WS-Policy? Existe tamb\'em
metamodelo deste padr\~ao? WS-Policy \'e amplamente conhecido e j\'a suportado por
diversos ambientes de execu\c c\~ao para aplica\c c\~oes orientadas a servi\c cos.   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
40 - Por que as regras de transforma\c c\~ao n\~ao foram descritas em ATL? 
\end{quotation}

\subsection{Discussion}

The main goal of $\pi$SOD-M is to provide a way for helping the development
of service-oriented application applications in the presence of non-functional
properties. Our work targets the specification and programming web application,
including these non-functional aspects (i.e., atomicity, security, performance,
persistence). In contrast to approaches such as WS-* , our work
specifies \textit{policies} for service compositions in an orthogonal way,
\textit{i.e} separating the specification of non-functional requirements from
the main functionalities of the application. The use of the WS-* standards
suppose that non-functional requirements are implemented according to the
knowledge that a programmer has of a specific application requirements, without
deriving them in a methodological way, thus leading to \textit{ad-hoc} solutions
that can be difficult to reuse. In our approach, once defined policies for a
given application, they can be reused and/or specialized for another application
with similar requirements.

Considering choreography and orquestration, a detailed description of the
difference between them will be present at Backgroud chapter in the final
version of the thesis' manuscript. These concepts will be described in this chapter,
together with other important concepts, which are: MDA, Service-Oriented
Development, Compositionof Services \cite{NguyenHPCM09} and NFRs
\cite{MylopoulosBook99,UszokBJ04,Chung2009,Yu97,AmyotM02}.

Considering the work proposed by D'Ambrogio \cite{DAmbrogio06} , this
work proposes a WSDL extension for describing QoS in Web Services, describing an
MDA approach with one level of transformation. The work describes not
a methodology proposal, but rather an extension of WSDL using MDA. Thus, we
believe that the proposed D'Ambrogio differs slightly from our approach.    

Regarding the ATL transformation, all transformations have been described in
natural language. Since there are more than one language for define
transformation rule, such as QVT and ATL, we prefer to omit these transformation
to the reader of the thesis. The transformations in ATL were not included in the
thesis manuscript because the rules have already been described in natural
language. Examples of ATL transformations presented in Environment shows the
general structure of ATL.

However, as a way of adding value to the the thesis, we will include
 the transformations described in ATL as an Appendix of the thesis.  



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  
  
\section{Systematic Review}
\label{sec:sytematic} 

\subsection{Questions}


\begin{quotation}\sf\footnotesize
\noindent
15 - Acredito que as Research Questions poderiam ser melhor formuladas. Por
exemplo, em rela\c c\~ao RQ1 (``How are NFRs modelled by existing methodologies for
developing reliable Web services''), as nota\c c\~oes para expressar RNFs quase
nunca est\~ao associadas a metodologias de desenvolvimento de software (muito menos a
metodologias -ainda muito escassas - de desenvolvimento orientado a servi\c
co). A maioria das nota\c c\~oes para expressar RNFs s\~ao definidas
isoladamente, pois o tratamento explícito de RNFs ainda \'e muito raro. Acredito que por conta disto
voc\^e n\~ao encontrou i-star, GRL, NFR e KAOS, pois exceto NFR, os outros n\~ao
est\~ao integrados a nenhuma metodologia de desenvolvimento de software.         
\end{quotation}


 
\begin{quotation}\sf\footnotesize
\noindent
16 - N\~ao entendi a RQ4 e nem as poss\'iveis respostas a RQ6  
\end{quotation}

 
 
\begin{quotation}\sf\footnotesize
\noindent
17 - Observando os strings utilizados para a busca nas bases bibliogr\'aficas, \'e
poss\'ivel observar que: no mundo de servi\c cos, o termo QoS \'e muito mais
comum do que ``non-functional requirements'' e s\~ao usados como sin\^onimos na \'area. Isto
pode ter tido um impacto muito grande nos resultados retornados.   
\end{quotation}

\subsection{Discussion}

The main goalin define the RQ4 was check if there is any `` standard''
or classification of NFR for service-oriented development. With this question we
wanted to verify whether it existed approaches to working with NFRs services in
the context of a methodology for service-oriented development. Thus, the results
about KAOS and i-star, for example, were not returned as a result.

About RQ6, in our analysis we would like to know if the non-functional
requirements addressed in the work analyzed consider service composition or not.


Finally, a change in the search query to consider QoS, would be:
\textsc{[Non-Functional requirements or Non-Functional properties or Non-Functional
attributes or QoS] And [Service oriented application development or Web
Service based applications development or Service Composition development]}

 
% 
% 
% \section{Questionamentos e Sugest\~oes do Prof. Nelson Souto Rosa}
% \label{sec:questions}
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 1 - Qual a no\c c\~ao de ``confiabilidade'' usada no trabalho? Apesar de constar
% no t\'itulo (``A methodology for building reliable service-based applications'') e
% em v\'arias partes do documento, a metodologia proposta e os meta-modelos n\~ao
% apresentam nenhuma caracter\'istica que sugira o desenvolvimento de aplica\c
% c\~oes deste tipo. Na pr\'atica, a proposta da tese aparenta ter sido concebida
% para o desenvolvimento de aplica\c c\~oes orientadas a servi\c cos em geral.      
% \end{quotation}
% 
% % ``Reliability is even more important  in  object-oriented  programming than 
% % elsewhere. Meyer presents in \cite{Meyer92,MeyerN93} how to reduce bugs by
% % building software components on the basis of carefully designed contracts.''
% % 
% % Thus, based on this concept, a software component, whether a service or not,
% % which is designed based on contracts has reduced the amount of bugs, becoming
% % more reliable. In the specific case of services, which are loosely coupled
% % components, the specification and verification of these contracts must be
% % performed by the services' orchestrator, who shall verify the validity and
% % execution of these contracts.
% % 
% % The concept of \textit{reliability} used in the thesis, is the concept presented
% % by \textit{Bertrand Meyer} \cite{Meyer92,MeyerN93,Meyer97} in his definition of
% % \textbf{Design by Contract}.
% % 
% % Bertrand Meyer \cite{Meyer97} gives these definitions, about
% % \textit{Correctness, Robustness} and \textit{Reliability} :
% % 
% % . \textit{Correctness}: The ability of software products to perform their exact
% % tasks, as defined by their specification.
% % 
% % . \textit{Robustness}: The ability of software systems to react appropriately to
% % abnormal conditions.
% % 
% % . \textit{Reliability}: A concern encompassing correctness and robustness.
% % 
% % As the contracts for service interfaces are designed to ensure the expected
% % result after the task performed by the service, and that if the contract is
% % broken, the service does not apply to the application, we try to ensure
% % the correctness by applying contracts in independent services.
% % 
% % Likewise with the robustness, after a contract is broken, the specification
% % describes alternative paths for the user does not notice the error.
% % 
% % Thus, we can say that the use of design by contract for services in
% % service-oriented applications can ensure the reliability of these
% % kind of applications.
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 2 - Senti falta de justificativas de porque a proposta foi desenvolvida apenas
% para Web services. Observe que existem diversos servi\c cos que n\~ao s\~ao Web,
% ou seja, n\~ao s\~ao descritos em WSDL, n\~ao s\~ao armazenados em UDDIs e usam outros
% protocolos de comunica\c c\~ao diferentes de SOAP.   
% \end{quotation} 
% 
% % Although not mentioned, the methodology can be applied to any service approach,
% % not necessarily Web services. If observed, the $\pi$-PEWS specifications
% % generated for the examples present not only WSDL. It is possible to use
% % the methodology even if the used approaches are JSON,
% % REST, Java RMI, WCF, and so on. As contracts are about functions, the
% % restrictions described  through the contracts can used for any
% % approach, not only Web services.
% % 
% % A more detailed discussion of this aspect will be inserted in the new version
% % of the thesis' manuscript.
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 3 - Al\'em da necessidade de remo\c c\~ao do termo ``reliable'' no t\'itulo,
% sugiro que o t\'itulo da tese tamb\'em deveria considerar o fato de que
% aplica\c c\~oes que tem servi\c cos como elementos de primeira classe s\~ao
% referidas na literatura como ``service-oriented applications'' e n\~ao
% ``service-based applications''. N\~ao sei se houve uma discuss\~ao sobre isto,
% mas esta diferen\c ca \'e significativa.
% \end{quotation}
% 
% % The use of the expression ``\textit{service-based}'' was used as a synonym for
% % ``\textit{service-oriented}''. We understand the need to better match the title,
% % for ``\textit{service-oriented}'' application. However, we consider it is
% % unnecessary to remove the word \textit{reliability}, because its concept is
% % based on the idea of contracts (see answer to question 1).
% % 
% % Thus the title will be updated to: ``\textbf{A Methodology for Building
% % Reliable Service-Oriented Applications.}''
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 4 - \'E preciso explicar no texto o que \'e uma aplica\c c\~ao orientada a
% servi\c co confi\'avel, ou seja, qual a no\c c\~ao de ``confiabilidade''
% adotada. Observe que ``confiabilidade'' tamb\'em \'e um RNF. Caracterizar bem a
% confiabilidade destas aplica\c c\~oes ajudaria a entender como a metodologia
% trata as particularidades deste requisito n\~ao funcional. Neste ponto, vale a
% pergunta: e se as aplica\c c\~oes precisassem ser ``seguras'' (outro requisito
% n\~ao funcional), a metodologia poderia ser tamb\'em aplicada?      
% \end{quotation}
% 
% %See answer to question 1. 
%  
% \begin{quotation}\sf\footnotesize
% \noindent
% 5 - Deveria haver uma discuss\~ao na tese sobre a consist\^encia dos modelos.     
% \end{quotation}
% 
% % *We will provide a discussion about consistency of models in the final version
% % of the thesis manuscript.
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 6 - Por que n\~ao foi feita nenhuma valida\c c\~ao ``quantitativa'' para mostrar quanto
% a metodologia proposta ``facilita o desenvolvimento de aplica\c c\~oes
% orientadas a servi\c co'' (ver defini\c c\~ao de valida\c c\~ao na pp. 116)? N\~ao h\'a evid\^encias de que a
% metodologia facilita o desenvolvimento de aplica\c c\~oes orientadas a servi\c co.
% \end{quotation}
% 
% % We will make an evaluation of the characteristics of the generated
% % specification. As our final result is a specification of service composition in
% % PEWS, we will evaluate quantitative data generated (in terms of lines of
% % specification).
% % 
% % We will evaluate with works that generate specifications for service
% % composition, such as the approach proposed by Nikola Milanovic
% % \cite{Milanovic2006} which generates specifications in B.
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 7 - N\~ao h\'a uma discuss\~ao de porque tratar RNF \'e dif\'icil ou porque SOC
% facilita o tratamento destes requisitos.
% \end{quotation}
%  
% 
%  
% \begin{quotation}\sf\footnotesize
% \noindent
% 8 - Por que Web services e n\~ao Servi\c cos foram considerados? Por que o trabalho
% considera apenas Web services? Existe uma raz\~ao particular para isto, uma vez
% que torna a solu\c c\~ao restrita ao universo de Web Services?  
% \end{quotation}
% 
% %See answer to question 2.
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 9 - Verificar a frase ``\ldots some proposals extend WSDL adding behavioral
% characteristics, such as PEWS[27], BPEL4WS\ldots'' Observe que BPEL4WS n\~ao \'e uma
% extens\~ao de WSDL. WSDL \'e uma nota\c c\~ao para defini\c c\~ao de interface de servi\c cos e
% WS-BPEL \'e uma notao para composi\c cao de servi\c cos, ou seja, s\~ao nota\c c\~oes
% com prop\'ositos muito distintos. Considere reescrever esta frase.    
% \end{quotation}
% 
% % ``\textit{\ldots some proposals specify services and its compositions by adding
% % behavioral characteristics, such as PEWS[27], BPEL4WS\ldots}''
% 
%  
% \begin{quotation}\sf\footnotesize
% \noindent
% 10 - Na frase a seguir n\~ao fica claro como MDA alinha os conceitos de RNFs e
% SOC: ``MDA [67] is an important approach for the alignment between highlevel
% information modelling, non-functional requirements\ldots''. Na pr\'atica, \'e
% preciso explicar porque o uso de MDA favorece/ajuda o tratamento de RNFs.
% \end{quotation}
% 
%  
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 11 - Observe na frase a seguir que WSDL e WS-BPEL n\~ao s\~ao ``plataformas de
% servi\c co'': ``MDA allows the specification of a system as an abstract model,
% which may be realized as a concrete implementation (program) for a particular service
% platform (e.g. WSDL, BPEL or PEWS).''    
% \end{quotation}
% 
% % ``MDA allows the specification of a system as an abstract model,
% % which may be realized as a concrete implementation (program) for a particular service
% % description or specification language (e.g. WSDL, BPEL or PEWS).''
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 12 - Rever ou explicar a frase a seguir: ``The design addresses the functional
% requirements while architecture provides the non-functional requirements like
% scalability, reliability and performance are realized.'' Esta frase sugere que o
% projeto (design) trata os requsitos funcionais enquanto a arquitetura trata os
% RNFs. Na pr\'atica, no entanto uma diferen\c ca b\'asica destes requisitos n\~ao \'e a etapa de desenvolvimento em que eles s\~ao tratados, mas o fato de que normalmente
% os requisitos funcionais est\~ao confinados (ou s\~ao implementados) em elementos
% pontuais da implementa\c c\~ao. Por sua vez, os RNFs s\~ao pervasivos, ou seja, est\~ao
% normalmente espalhados em toda a implementa\c c\~ao. Por exemplo, para ser seguro,
% todas as partes do sistema precisam ser seguras.       
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize 
% \noindent
% 13 - Sugiro que tamb\'em seja discutido na tese o seguinte ponto: associar RNFs a
% ``composi\c c\~oes de servi\c cos'' ou a ``servi\c cos'' pode ser muito
% dif\'icil, pois alguns RNFs s\~ao ``distributivos''. Imagine que o
% desenvolvedor define que a composi\c c\~ao (e.g., formada por 5 servi\c cos) \'e segura. Isto implica (mesmo que n\~ao seja dito
% pelo desenvolvedor) que todos os servi\c cos precisam ser seguros e que todas as
% comunica\c c\~oes entre ele s\~ao seguras. Mas, imagine que um dos servi\c cos
% n\~ao \'e seguro. Como esta situa\c c\~ao \'e tratada pela metodologia? Quais os artefatos
% gerados no final?      
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 14 - Senti falta de cita\c c\~oes a trabalhos de John Mylopoulos, cujo livro e
% artigos s\~ao os mais importantes na \'area de RNFs. Em particular, o livro
% ``Non-Functional Requirements in Software Engineering'' \'e uma esp\'ecie de
% ``bíblia'' da \'area. Al\'em desta, existe uma vasta literatura sobre RNFs n\~ao
% mencionada no texto: KAOS, i-star, NFR, URN/GRL (padr\~ao da ITU-T). A quase totalidade dos
% elementos presentes nos metamodelos propostos j\'a constam nos trabalhos
% mencionados acima, e.g., NF-Attribute, NF-Requirement, NF-Action, NF-Properties.
% Inclusive, j\'a existem tamb\'em metamodelos e UML profiles para modelagem de RNFs. 
% 
% 
% Por fim, tamb\'em senti falta de men\c c\~ao aos padr\~oes WS-* que se
% relacionam a RNFs: WS-Policy, WS-SecurityPolicy, WS-Reliability, WS-Transaction,
% e ``Quality Model for Web Services''.
% \end{quotation}
% 
%  
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 15 - Acredito que as Research Questions poderiam ser melhor formuladas. Por
% exemplo, em rela\c c\~ao RQ1 (``How are NFRs modelled by existing methodologies for
% developing reliable Web services''), as nota\c c\~oes para expressar RNFs quase
% nunca est\~ao associadas a metodologias de desenvolvimento de software (muito menos a
% metodologias -ainda muito escassas - de desenvolvimento orientado a servi\c
% co). A maioria das nota\c c\~oes para expressar RNFs s\~ao definidas
% isoladamente, pois o tratamento explícito de RNFs ainda \'e muito raro. Acredito que por conta disto
% voc\^e n\~ao encontrou i-star, GRL, NFR e KAOS, pois exceto NFR, os outros n\~ao
% est\~ao integrados a nenhuma metodologia de desenvolvimento de software.         
% \end{quotation}
% 
% 
%  
% \begin{quotation}\sf\footnotesize
% \noindent
% 16 - N\~ao entendi a RQ4 e nem as poss\'iveis respostas a RQ6  
% \end{quotation}
% 
% 
%  
% \begin{quotation}\sf\footnotesize
% \noindent
% 17 - Observando os strings utilizados para a busca nas bases bibliogr\'aficas, \'e
% poss\'ivel observar que: no mundo de servi\c cos, o termo QoS \'e muito mais
% comum do que ``non-functional requirements'' e s\~ao usados como sin\^onimos na \'area. Isto
% pode ter tido um impacto muito grande nos resultados retornados.   
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 18 - Senti falta tamb\'em de uma discuss\~ao sobre ``correla\c c\~ao'', ``conflitos'' e
% ``prioridade'' entre RNFs. Estes dois aspectos s\~ao muito discutidos quando
% fala-se em RNFs.   
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 19 - Observe que o trabalho de D'Ambrogio [34] tamb\'em tem MDA, RNFs e servi\c cos,
% ou seja, ele deveria estar na mesma \'area que a proposta da tese na Figura 3. 
% \end{quotation}
% 
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 20 - Esclarecer o que s\~ao Business Services. Este termo n\~ao \'e comum na \'area de servi\c cos. 
% \end{quotation}
% 
%   
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 21 - Uma das RQs poderia ser ``metodologias fazem o desenvolvimento de
% composi\c c\~oes por orquestra\c c\~ao ou por coreografia?'' Isto mereceria tamb\'em uma
% discuss\~ao na tese, pois s\~ao as estrat\'egias normalmente usadas na computa\c c\~ao
% orientada a servi\c cos. Ainda relacionado a isto, outro ponto que deveria ter sido
% discutido na tese \'e o fato de que metodologias para este tipo de desenvolvimento
% tem como etapas principais a ``sele\c c\~ao'' e a ``combina\c c\~ao'' de servi\c cos. Compare
% estas etapas com as etapas tradicionais.       
% \end{quotation}
% 
%   
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 22 - N\~ao tenho certeza, mas acredito que alguns elementos dos metamodelos da
% $\pi$SOD-M j\'a tenham sido definidos na SOD-M. Seria interessante, se isto est\'a
% acontecendo, destacar estes elementos para deixar claro ao leitor os elementos
% que s\~ao exclusivos da $\pi$SOD-M.    
% \end{quotation}
%  
% % The concepts added by our approach as form to extend SOD-M proposal is
% % highlighted in our meta-models by dotted lines around the entities. The new
% % concepts are:
% % 
% % . \textit{$\pi$-UseCase} model: Constraint, Constraint Type, Non-Functional
% % Requirement, and Non-Functional Attribute.
% % 
% % . \textit{$\pi$-ServiceProcess} model: Contract, Assertion, Assertion Property,
% % Exceptional Behaviour.
% % 
% % . \textit{$\pi$-ServiceComposition} model: Policy, Rule, Event Type, Variable,  Non-Functional
% % Requirement. 
% % 
% % . \textit{$\pi$-PEWS} model: There was no definition of the $\pi$-PEWS concepts
% % in the original SOD-M. Thus, all elements are new. 
% % 
% % The main purpose of adding these elements is the need to better represent the
% % constraints associated with the services and how these restrictions can be
% % represented by each meta-model entity. As the restrictions associated with the
% % services are refined at each iteration, the representation also changes in each
% % meta-model.    
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 23 - Observando a Figura 4, \'e poss\'ivel observar que $\pi$SOD-M tem as mesmas
% etapas de SOD-M, mas com foco no RNFs. Isto sugere (posso estar enganado) que toda a
% parte ``funcional'' foi aproveitada na SOD-M. Isto \'e verdade?   
% \end{quotation}
% 
% % Yes, this is true.  
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 24 - DEVISE \'e uma metodologia?  
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 25 - N\~ao \'e muito claro como um ``requisito n\~ao-funcional'' pode ser representado
% por um ``use case''.
% \end{quotation}
% 
%   
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 26 - Talvez esteja claro no texto, mas n\~ao ficou claro para mim os mapeamentos
% ``Constraint'' -> Contract e Contract-> Policy s\~ao realizados.
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 27 - Senti falta de uma descri\c c\~ao precisa do que sejam NF-Attributes,
% NF-Properties e NF-Requirements. 
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 28 - N\~ao entendi a frase ``The quality properties at the system level represent
% a behaviour that is part of the workflow.''
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 29 - Observar esta parte ``$\pi$SOD-M is a MDA (Model Driven Architecture) based
% methodology. It provides a framework for building service compositions
% considering their non-functional requirements.'' A metodologia fornece um
% framework? Os conceitos de metodologia e framework s\~ao muito distintos.   
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 30 - N\~ao est\'a muito clara (justificada) a necessidade de um ``Process Model'' e
% um ``Composition Model''. Observe que em nota\c c\~oes como WS-BPEL os elementos destes
% dois modelos est\~ao de certa forma juntos, ou seja, talvez seja interessante
% justificar porque a metodologia adota esta separa\c c\~ao.    
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 31 - Senti falta de uma descri\c c\~ao passo-a-passo da Figura 5, por exemplo,
% ``Inicialmente tem-se uma especifica\c c\~ao de um processo de neg\'ocio que \'e
% transformado em um UseCase model...'' Esta explica\c c\~ao at\'e existe, mas est\'a
% dilu\'ida nas p\'aginas subsequentes do texto quando voc\^e diz ``After modelling the
% system services and feature...'' (pp. 62). Como esta figura \'e muito importante,
% ela deveria ser bem descrita.      
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 32 - N\~ao h\'a uma explica\c c\~ao sobre (i) porque a metodologia foi estruturada em
% tr\^es vis\~oes (Business, System and Policy) e (ii) como chegou-se a estas tr\^es
% vis\~oes.  
% \end{quotation} 
% 
% % The Business and Services views were inherited from SOD-M \cite{CastroMV11}, the
% % Policy view encompass the elements and concepts necessary to describe constraints for
% % services. Thus, it was included in the structure of SOD-M the Policy view
% % as a way to represent these concepts during the application design.   
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 33 - Sugiro uma explica\c c\~ao sobre o mapeamento apresentado na Figura 16. Por
% exemplo, \'e preciso justificar porque uma ``Business Service'' \'e representado em
% UML por um ester\'otipo.  
% \end{quotation}
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 34 - Observe que processos em WS-BPEL possuem muito mais do que ``sequence of
% activities'' (ver frase ``It can be visualized with a flowchart as a sequence of
% activities with interleaving decision points''). Na pr\'atica, por tr\'as desta
% minha observa\c c\~ao est\'a a constata\c c\~ao de que o modelo para defini\c c\~ao de processos proposto ( PI-ServiceProcess) \'e muito mais simples do aqueles apresentados em
% nota\c c\~oes como URN e WS-BPEL (usadas com o mesmo objetivo e que j\'a possui
% metamodelos).    
% \end{quotation}
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 35 - Quem \'e o ``Application designer''? Qual o perfil? \'e algu\'em de neg\'ocio ou de
% TI? Isto \'e importante estar definido na metodologia, pois provavelmente existem
% v\'arios atores (business expert, qos expert, TI expert) envolvidos nas v\'arias
% etapas da metodologia. Por exemplo, algu\'em de neg\'ocio seria capaz de definir uma
% express\~ao como estas apresentadas na Figura 20 (e.g., $\#$bankBlance $>$
% paymentValue \&\& \ldots ). Veja ainda na p\'agina 85: quem \'e o
% ``designer'' referido na frase ``The designer must specify\ldots''.      
% \end{quotation}
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 36 - Que linguagens s\~ao estas ``behavioural web service interface languages''?    
% \end{quotation}
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 37 - Seria interessante justificar porque a linguagem PEWS foi escolhida para a
% implementa\c c\~ao. Isto remete a outro importante, a metodologia \'e desacoplada desta
% linguagem, ou seja, ela suportaria a gera\c c\~ao de composi\c c\~oes execut\'aveis em
% WS-BPEL?   
% \end{quotation}
% 
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 38 - Por que as pol\'iticas n\~ao s\~ao descritas em WS-Policy? Existe tamb\'em
% metamodelo deste padr\~ao? WS-Policy \'e amplamente conhecido e j\'a suportado por
% diversos ambientes de execu\c c\~ao para aplica\c c\~oes orientadas a servi\c cos.   
% \end{quotation}
% 
% % Resposta
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 39 - J\'a existia um metamodelo de PEWS?   
% \end{quotation}
% 
% % No. The PEWS meta-model was specified based on its language and its extension (during the PhD
% % stage in Grenoble), where we added the concepts of contracts.
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 40 - Por que as regras de transforma\c c\~ao n\~ao foram descritas em ATL? 
% \end{quotation}
% 
% % All transformations were also described in ATL, but were not included in the
% % thesis' manuscript. We will insert as an appendix of the
% % thesis, or as a link address where anyone can download (with the specific
% % referenc in the text of the thesis).
%    
% \begin{quotation}\sf\footnotesize
% \noindent
% 41 - Senti falta dos requisitos do ambiente de desenvolvimento proposto. Veja
% que a Figura 41 j\'a mostra a arquitetura. Quais os requisitos que geraram esta arquitetura?
% \end{quotation}
%  
% % The environmental requirements are the Eclipse Modelling (Galilleo or higher)
% % and all plugins proposed, \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
% % $\pi$-SerciveComposition} and \textit{$\pi$-PEWS} editors; and also the
% % transformation plugins. Because the environment is proposed in the
% % context of Eclipse, the environmental requirements are also the same needed to
% % utilize the Eclipse tool.
%  
% \begin{quotation}\sf\footnotesize  
% \noindent
% 42 - O ambiente n\~ao deveria ser estruturado em ``vis\~oes'' como a metodologia?
% \end{quotation}
% 
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 43 - Ao inv\'es de ``estudos de caso'' colocaria ``Examples''. Removeria o Estudo
% de Caso 1, pois ele foi usado em toda a tese e todos os principais elementos j\'a
% foram apresentados no Cap\'itulo 3 (inclusive as figuras s\~ao as mesmas). 
% \end{quotation}
% 
% % As suggested, we will use the term ``\textbf{\textit{Examples}}'' to the case
% % studies presented. Likewise, instead of ``\textit{Validation}'', we use
% % the term ``\textbf{\textit{Evaluation}}'', in Chapter 5, as a way to better represent
% % what was done.
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 44 - N\~ao fica claro o que \'e a ``an\'alise qualitativa'' mencionada.
% \end{quotation}
% 
% % Resposta
% 
% \begin{quotation}\sf\footnotesize
% \noindent
% 45 - Explicar melhor os trabalhos futuros. Evite itemiz\'a-los.
% \end{quotation}
% 
% % The items will be described more detailed in order to make clear what will be
% % done in \textit{Future Work}.
% 
% \section{Respostas aos questionamentos e sugest\~oes do Prof. Nelson Souto Rosa}
% \label{sec:respostas}
% 
% According with the questions presented and listed above, this document aims to
% present and detail the concepts, definitions and key points that were not clear
% in the description text of the thesis which was sent to committee members.    
% 
%  
% % De acordos com os questionamentos apresentados e listados acima, este documento
% % tem por objetivo apresentar e detalhar os conceitos,
% % defini\c c\~oes e pontos principais que n\~ao ficaram claros na descri\c c\~ao do texto da
% % tese que foi enviado aos membros da banca.
% 
% Os aspectos que ser\~ao discutinos neste documento de resposta visa proporcionar
% uma defini\c c\~ao mais coerente e satisfat\'oria no que diz respeito aos conceitos relacionados a:
% (i) Requisitos n\~ao-funcionais, (ii) Aplica\c c\~oes orientadas a servi\c co, (iii)
% desenvolvimento dirigido a modelos e tamb\'em (iv) como os apresentamos no
% contexto da metodologia proposta, $\pi$SOD-M. \'E importante destacar que estas
% sugest\~oes e as respostas aos questionamentos ser\~ao considerados para a vers\~ao final do documento da tese, como forma de
% melhorar e deixar mais claro ao leitor os benef\'icios de se utilizar a
% metodologia $\pi$SOD-M, bem como os conceitos/defini\c c\~oes nela
% apresentados.
%  
% Sempre que for apresentado a nota\c c\~ao $R_n$ no decorrer
% do texto, esta faz refer\^encia a qual d\'uvida/questionamento estamos tentando
% responder. Dessa forma, caso exista a referência $R_3$, estamos fazendo a
% referência a responta ao terceiro questionamento listado acima, da mesma forma
% que $R_{45}$ \'e a resposta ao \'ultimo questionamento apresentado acima.
%  
% \bigskip
% \bigskip
% 
%  
% A metodologia $\pi$SOD-M foi concebida com o intuito de agregar valor a
% metodologia SOD-M \cite{CastroMV11}, e também minimizar o problema de modelagem de
% requisitos não funcionais para aplicações orientadas a serviços. A principal contribuição deste
% trabalho é fornecer uma estrutura na qual seja possível descrever/espeficicar
% restrições sobre serviços desde a concepção inicial (nível mais abstrato) do
% desenvolvimento de sistemas. Nossa proposta visa refinar as restrições
% (em termos de ``\textit{constraints}'' $>>$ ``\textit{contracts}'' $>>$
% ``\textit{policies}'') a cada iteração do desenvolvimento. Entendemos que vários
% trabalhos existentes na literatura abordam a especificação e modelagem de
% propriedades não funcionais em diversos aspectos. Estas abordagens detalham o
% projeto de requisitos específicos como performance, segurança, usabilidade, confiabilidade,
% dentre outros. No entanto, aspectos importantes do desenvolvimento não são
% considerados e isso dificulta, especifalmente, o desenvolvimento de aplicações
% orientadas a serviços.
% 
% Bertrand Meyer \cite{Meyer92,MeyerN93,Meyer97} argumenta que ``confiabilidade é
% importante no desenvolvimento de aplicações. Meyer argumenta que reduzir erros
% através da construção de componentes de software através de contratos proporciona uma maior
% confiabilidade a aplicação que está sendo desenvolvida.
% 
% Com base neste conceito \cite{Meyer92,MeyerN93,Meyer97}, um componente de
% software, seja um serviço ou não, que é projetado com base em contratos pode reduzir a quantidade de erros,
% tornando-se mais confiável. No caso específico de serviços, que são
% componentes de baixo acoplamento, a especificação e verificação
% desses contratos pode ser realizada pelo ``orquestrador'' dos serviços, que deve
% verificar a validade e execução desses contratos.
% 
% O conceito de confiabilidade utilizada na tese é a definição apresentada
% por Bertrand Meyer \cite{Meyer92,MeyerN93,Meyer97} em sua definição de
% \textbf{Design by Contract}. Para Meyer, confiabilidade engloba corretude e
% robustez.
% 
% Corretude é a capacidade dos produtos de software executarem suas
% tarefas como definidos por sua especificação; enquanto Robustez é a capacidade
% de sistemas de software reagir adequadamente a condições anormais.
% 
% Como os contratos para interfaces de serviço são projetados com o objetivo de
% assegurarem, o resultado esperado depois da execução do serviço está
% relacionado com a não quebra do contrato. Se o contrato é quebrado, o
% serviço não se aplica a necessidade da aplicação. Com isso, tentamos garantir a corretude através da aplicação de
% contratos em serviços. Da mesma forma ocorre com o conceito de robustez,
% depois que um contrato é quebrado, a especificação do contrato define caminhos
% alternativos/excepcionais para o usuário não perceber o erro ($R_1$ e $R_4$).
% 
% Assim, podemos afirmar que o uso de \textit{Design by Contract} em aplicações
% orientadas a serviços pode garantir a confiabilidade ao software gerado.
% 
% \bigskip
% \bigskip
% 
% 
% Embora não mencionado, a metodologia pode ser aplicada a qualquer abordagem de
% serviço, não necessariamente Serviços web. Se observado, as especificações
% $\pi$-PEWS geradas para os exemplos no capítulo de validação apresentam não
% apenas WSDL. É possível utilizar a metodologia mesmo se as abordagens utilizadas
% na construção (reuso) dos serviços são JSON, REST, Java RMI, WCF, e assim por
% diante. Como os contratos são sobre funções, as restrições descritas através dos
% contratos podem ser aplicada para qualquer abordagem, não apenas para os
% Serviços web. 
% 
% Está implícito no manuscrito da tese que usamos apenas Serviços web. Isso
% acontece pelo fato de trabalharmos apenas no nível de especificação, e neste
% nível não há uma preocupação com qual abordagem irá implementar a especificação. 
% No entanto, uma discussão mais detalhada sobre esse aspecto será inserida na
% nova versão do manuscrito da tese ($R_2$ e $R_8$). 
% 
% 
% 
% \bigskip
% \bigskip
% 
% 
%  
% O t\'itulo da tese foi modificado de ``\textit{A
% Methodology for Building Reliable Service-Based Applications}'' para `\textit{A
% Methodology for Building Service-Oriented Application in the Presence of
% Non-Functional Properties}'' como forma de deixar o t\'itulo mais expressivo e
% correto em rela\c c\~ao as \'areas chaves do trabalho. Entendemos que a literatura
% utiliza a express\~ao \textit{Service-Oriented}, em detrimento ao adotado
% anteriormento \textit{Service-Based}. Apesar desta \'ultima express\~ao ter sido
% utilizada como sin\^onimo da primeira, \'e importante a adequa\c c\~ao com a \'area. Da
% mesma maneira, retiramos o termo ``\textit{reliable}'' para que este n\~ao seja
% entendido de maneira espec\'ifica como a \'unica propriedade a ser considerada no
% trabalho, em detrimento das demais. Para isso adotamos a express\~ao
% ``\textit{Non-Functional Properties}'' ($R_3$).
% 
% \bigskip
% \bigskip
% 
% 
% Enquanto MDA utiliza uma linguagem de modelagem orientada a objetos
% precisa (ou seja, UML) como tecnologia núcleo, ele não insiste na
% importância de transformações do modelo precisos e automatizado para a concepção e implementação de
% mapeamentos de PIMs para PSMs, ou de PSMs para código. MDA não oferece
% mecanismos para se verificar a de consistência dos modelos desenvolvidos. No
% entanto, existem alguns trabalhos que tem como foco principal verificar a
% consitência destes modelos usando alguma agordagem formal
% \cite{Varro04,PaigeV12}. 
% 
% A verificação de consistência ``sintática'' dos modelos é realizada por
% ferramentas de definição e transformação de modelos MDA, como por exemplo o
% \textit{Eclipse Modelling}. Como não era o foco inicial do nosso trabalho a
% verificação semântica dos modelos e do código gerado por eles (com o objetivo de analisar a sua consistência), não
% apresentamos no texto da tese uma discussão sobre este assunto. No entanto,
% identificamos como trabalho futuro (pg. 146) a intenção de formalizar as regras
% de transformação dos modelos ($R_5$).
% 
% \bigskip
% \bigskip
% 
% Na versão final do manuscrito da tese, será realiza uma análise do código
% gerado em $\pi$-PEWS. Como a metodologia gera a especificação da aplicação no
% que diz respeito a serviços, workflow e contratos, iremos fazer uma comparação com
% abordagem semelhantes \cite{Milanovic2006} que consideram algum tipo de
% linguagem de especificação, como o método B ($R_6$). 
% 
% 
% \bigskip
% \bigskip
% 
% 
%  Garantir propriedades não funcionais é um desafio do desenvolvimento de
%  aplicações em geral, em especial aplicações distribuidas que dependem de
%  recursos de rede para que os serviços sejam executados.
%  No entanto, como serviços são componentes independentes e tem uma granularidade
%  mais fina, garantir que restrições sejam satisfeitas nestes serviços é mais fácil. Como
%  cada serviço disponibiliza sua interface de acesso para que as ações sejam
%  chamadas, os clientes destes serviço tem a possibilidade de verificar se o
%  resultado o satisfaz ou não, inclusive durante a execução da aplicação. Por
%  outro lado, a garantia de prorpiedades não funcionais em composição de serviço
%  não é tão trivial de resolver. Isso ocorre pelo fato dos requisitos não
%  funcionais, na maioria das vezes, terem características concorrentes ou até
%  opostas no que diz respeito a tais requisitos. Por exemplo, para se
%  proporcionar segurança, todos os serviços da composição devem ser seguros. Para
%  se garantir tempo de responta satisfatório, todos os serviços da composição
%  devem fornecer os resultados obedecendo as restrições do cliente. No pior caso
%  em relação a garantia de requisitos não funcionais em composição de serviços,
%  se um serviço garante a segurança e outro performance, as restrições como um
%  todo acabam não sendo garantidas. 
%  
%  Devido a estes problemas, os requisitos não funcionais são tratados em serviços
%  de maneira particular, por exemplo, a maioria dos trabalhos tentam garantir
%  requisitos específicos na modelagem de aplicações orientadas a serviços.
%  Sabendo desse problema, tentamos fornecer com o nosso trabalho uma abordagem um
%  pouco mais geral baseada em contratos para os serviços presentes na
%  especificação do workflow. Os contratos em $\pi$-PEWS podem ser especificados
%  tanto para serviços simples ou compostos. O tratamento que damos no caso de serviços compostos é
%  que caso haja algum conflito em relação aos contratos, o contrato é quebrado e
%  a composição não é satisfatória para a execução da aplicação. É importante
%  destacar que como nossa abordagem é baseada em contratos para serviços, a
%  garantia das propriedades não funcionais está diretamente relacionado a
%  verificação dos contratos, entradas e saídas desejadas para um serviço simples
%  ou composto. ($R_7$)
%  
%  \bigskip
% \bigskip
% 
% De acordo com a frase seguinte,
% 
% ``\textit{\ldots some proposals extend WSDL adding behavioral characteristics,
% such as PEWS[27], BPEL4WS\ldots }''
% 
% como esta continha informação inconsistente, a atualizamos para:
% 
% ``\textit{\ldots some proposals specify services and its compositions by adding
% behavioral characteristics, such as PEWS[27], BPEL4WS\ldots}'' ($R_9$). 
%  
%  
%  \bigskip
%  \bigskip
%  
%  
%  MDD é uma abordagem importante para alinhar informações na modalagem de níveis
%  mais abstratos e requisitos não funcionais. Como no desenvolvimento baseado em
%  modelos, as informações vão sendo refinadas a cada nível através de
%  transformação de modelos, os NFRs podem ter sua definição melhor descrita.
%  
% Cada vez mais MDD é empregado para orientar o desenvolvimento com foco na
% geração de código a partir de modelos. Diferentemente, a modelagem de aspectos e
% propriedades não-funcionais continua difícil. Modelos que descrevem requisitos
% não-funcionais pode ser utilizados para expressar, na fase de especificação,
% características transversais da aplicação. A medida que é realisado o
% desenvolvimento destes modelos, propriedades essenciais do software são
% apresentadas de maneira mais concreta \cite{Rottger04}.
%  
%  O desafio no uso de MDD para na modelagem dos aspectos 
%  transversais da aplicação desde o nível mais abstrato de design é a
%  capacidade de utilizar diferentes tipos de modelos para diferentes fins e
% compreender as diferenças entre as terminologias para os aspectos não
% funcionais \cite{LimingZhu2009}. ($R_{10}$)
%  
%  \bigskip
% \bigskip
% 
% Considerando que WSDL, BPEL e PEWS não são plataformas de serviços, mas
% linguagens para descrição e especificação de serviços, descrevemos que:
% 
%  ``\textit{MDA allows the specification of a system as an abstract model, which may
%  be realized as a concrete implementation (program) for a particular service
%  description language or specification language (e.g. WSDL, BPEL or PEWS).}''
%  ($R_{11}$).
%  
%  \bigskip
%  \bigskip
%  
%  
%  A frase: 
%  
%  ``The design addresses the functional
% requirements while architecture provides the non-functional requirements like
% scalability, reliability and performance are realized.'' 
% 
% será removida. ($R_{12}$)
% 
% \bigskip
% \bigskip
% 
% 
% O Objetivo da RQ4 foi verificar de existia algum ``padrão'' ou classificação de
% NFR para metodologias de desenvolvimento. Com essa pergunta procuramos verificar
% se já existiam abordagens que trabalhavam com NFRs para serviços, no contexto de
% uma metodologia desenvolvimento. Dessa forma, os resultados sobre KAOS e i-star,
% por exemplo, não foram retornados como resultado. ($R_{15}$).
% 
% \bigskip
% \bigskip
% 
% 
% 
% 
% Em relação a RQ4, nós já estamos desenvolvendo um trabalho específico de análise
% mais detalhada através de uma outra revisão sistemática para requisitos não-funcionais. Uma Query
% várida para um melhor resuldado poderia ser expressa através de:
% 
% \textsc{[Non-Functional requirements or Non-Functional properties or Non-Functional
% attributes or QoS] And [Service oriented application development or Web
% Service based applications development or Service Composition development]} 
% 
%  Sobre a RQ6, queremos saber em nossa análise se os requisitos não-funcionais
%  tratados no trabalho analisado consideram serviços simples ou compostos. ($R_{16}$ e
%  $R_{17}$)
%  
%  \bigskip
%  \bigskip
%  
%  D'Ambrogio \cite{DAmbrogio06} propoe uma extensão WSDL para descrever QoS em
%  Web Services, descrevendo uma abordagem em MDA de apenas 1 nível de transformação. A proposta
%  de D'Ambrogio não está propondo uma metodologia, mas sim uma extensão de WSDL
%  usando MDA. Dessa forma, entendemos que a proposta de D'Ambrogio se distingue
%  um pouco da nossa abordagem. ($R_{19}$)
%  
%  \bigskip
%  \bigskip
% 
% 
% Serviços de negócios são serviços que fazem parte de um requisito negócio e
% atende a uma necessidade de usuário. BPMN define o conceito de \textit{Service
% operation} que é uma operação de um serviço que faz parte do processo de
% negócio \cite{bpmn}. Na área de serviços, um business service é representado
% por um serviço (ou composição) que será executado no processo de negócio.
% ($R_{20}$)
% 
% 
% 
% 
%   \bigskip
%  \bigskip
%   
% Uma descrição detalhada da diferença entre orquesteação e coreografia de
% serviços estará presente no capítulo de Backgroud na versão final do manuscrito
% da tese como sugerido. Estes conceitos serão descritos neste capítulo,
% aliado a outros conceitos importante, que são: MDA, Serviços (com a
% diferenciação entre orquestração e coreografia), Composição de Serviços
% \cite{NguyenHPCM09} e Requisitos não funcionais
% \cite{MylopoulosBook99,UszokBJ04,Chung2009,Yu97,AmyotM02}. ($R_{21}$ e $R_{14}$) 
% 
% 
% \bigskip
% \bigskip
% 
% Os conceitos inseridos pela nossa abordagem como forma de estender SOD-M foram
% destacados no manuscrito da tese com linhas pontilhadas ao redor do conjunto de
% entidades. Os conceitos descritos em cada meta-modelo de  $\pi$SOD-M que foram
% acrescentados são:
% 
%  
% . Meta-modelo \textit{$\pi$-UseCase}: Constraint, Constraint Type,
% Non-Functional Requirement, and Non-Functional Attribute.
% 
% . Meta-modelo \textit{$\pi$-ServiceProcess}: Contract, Assertion,
% Assertion Property, Exceptional Behaviour.
% 
% . Meta-modelo \textit{$\pi$-ServiceComposition}: Policy, Rule, Event Type,
% Variable,  Non-Functional Requirement.
% 
% . Meta-modelo \textit{$\pi$-PEWS}: Não existia nenhuma definição dos
% conceitos de $\pi$-PEWS em SOD-M. Todos os elementos do meta-modelo de  $\pi$-PEWS foram
% definidos a partir de sua linguagem. 
% 
% $\pi$SOD-M herda toda a parte funcional de SOD-M. ($R_{22}$ e $R_{23}$)
% 
%   \bigskip
% \bigskip
%  
% Apesar da metodologia DEVISE \cite{DEVISE} não ser uma metodologia de
% desenvolvimento, ela é uma metodologia para definição de infra-estrutura de Serviços web. Por este motivo inserimos esta
% referência como como trabalho relacionado no capítulo de Estado da Arte (cap.
% 2). ($R_{24}$)
% 
% 
% \bigskip
% \bigskip
% 
% Em $\pi$SOD-M, um \textsc{Use Case} tem um conjunto de \textsc{Constraints} (em
% $\pi$-UseCase Model). As \textsc{Constraints} são agrupadas em \textsc{Contratos}, onde as
% \textsc{Constraints} de um mesmo caso de uso se transformam em
% \textsc{Assertions}, e essas \textsc{Assertions} compoem um contrato (em
% $\pi$-ServiceProcess Model). Por fim, \textsc{Contratos} com propriedades
% não-funcionais comuns (por exemplo, segurança), são agrupados em uma
% \textsc{Policy} (em $\pi$-ServiceComposition Model). ($R_{26}$)
% 
% 
% \bigskip
% \bigskip
% 
% 
% 
% A frase \ldots
% 
% ``\textit{The quality properties at the system level represent
% a behaviour that is part of the workflow.}''
% 
% quer dizer que as propriedades não funcionais do workflow (*que são
% descritas como \textit{assertions}, definidas através de pré ou pós-condições*),
% representam o comportamento desejado de cada parte (ação/serviço) do workflow. Esse conceito
% está baseado na definição de Design by Contract \cite{Meyer97}. 
% 
% No entanto, entendemos que a frase não está totalmente clara e iremos modificar
% para:
% 
% ``\textit{The quality properties at the system level, which are defined as assertions
% (pre- and post-conditions), represent the behaviour aspects required of the
% actions that is part of the main workflow.}'' ($R_{28}$) 
% 
% 
% 
% \bigskip
% \bigskip 
% 
%  
% Na frase:
% 
% ``\textit{$\pi$SOD-M is a MDA (Model Driven Architecture) based
% methodology. It provides a framework for building service compositions
% considering their non-functional requirements.}''
% 
% framework significa uma estrutura que engloba conceitos básicos para resolver
% algum problemas. Neste caso específico a metodologia provê um conjunto de
% conceitos, passos e transformações para se desenvolver aplicações orientadas a
% serviços, na presenta de requisitos não-funcionais. ($R_{29}$)
% 
% \bigskip
% \bigskip
%  
% A figura 5 será descrita mais detalhadamente na versão final do manuscrito da
% tese.
% 
% Esta figura descreve o passo a passo do desenvolvimento baseado em $\pi$SOD-M.
% A partir dos documentos de especificação de negócio e especificação de
% requisitos \cite{scube2010book}, o modelo de $\pi$-UseCase é desenvolvido. A
% partir deste modelo é realizada uma sequência de transformações com o objetivo
% de melhor refinar os conceitos necessários para o desenvolvimento.
% A partir do modelo de $\pi$-UseCase, o qual representa os casos de uso,
% requisitos e restrições da aplicação, o modelo de $\pi$-ServiceProcess é gerado. 
% 
% O modelo de $\pi$-ServiceProcess descreve o processo de negócio a ser executado,
% e suas respectivas restrições. A partir deste modelo, o modelo de 
% $\pi$-ServiceComposition é gerado. Este modelo é semelhante ao anterior, no
% entanto descreve quais serviços externos se relacionam com cada ação/operação no
% processo de negócio. 
%  
% A partir do modelo de  $\pi$-ServiceComposition é possível gerar uma
% especificação para qualquer linguage que descreva composição de serviços. No
% caso específico do nosso trabalho, foi gerado código $\pi$-PEWS. No entanto,
% é possível que seja gerado código para qualquer linguage, mas é necessário a
% descrição do meta-modelo da linguagem e as regras de transformação.
% 
%  O objetivo principal de se ter dois modelos para descrever o processo de
%  execução de serviço $\pi$-ServiceProcess e $\pi$-ServiceComposition é fazer com
%  que haja uma separação clara das necessidades de negócio, e quais serviços
%  iram implementar estas necessidades. Apesar de WS-BPEL já definir conceitos
%  semelhantes, o nosso objetivo foi também simplificar a descrição destes
%  processo. ($R_{30}$, $R_{31}$ e $R_{34}$)
% 
% \bigskip
% \bigskip
%  
% 
% As visões de Negócios e Serviços (Business e Service) foram herdadas de
% SOD-M \cite{CastroMV11}, a visão de Política (Policy) visa abranger os elementos
% e conceitos necessários para descrever restrições de serviços. Assim, foi
% incluído na estrutura original de SOD-M esta nova visão como uma
% forma de representar os aspectos não-funcionais durante o projeto da aplicação.
% ($R_{32}$)
% 
% 
% 
% \bigskip
% \bigskip
% 
% A figura 16 descreve como representamos os elementos de um modelo de
% $\pi$-UseCase através de UML. Um Business Service não é representado através de
% um esteriótipo. O único elemento que é representado através de esteriótipo neste
% modelo é uma \textit{Constraint}. Um \textit{Business Service} é identificado
% apenas como um comentário. Este comentário está ligado a um caso de uso. Isso
% significa que este caso de uso será uma ação da aplicação que fará parte de
% um serviço de negócio. Um serviço de negócio será uma ação/serviço simples da
% aplicação que está sendo desenvolvida, ou um serviço composto. Nesse caso a
% figura 16, semelhante as figuras 17 e 18 não mostra um mapeamento, mas como os
% conceitos do meta-modelo podem ser representados através de UML. ($R_{33}$)
% 
% \bigskip
% \bigskip
% 
% A linguagem $\pi$-PEWS foi escolhida para implementação pelo fato de já estar
% trabalhando com essa linguagem durante toda a tese, e pelo fato também desta
% linguagem ter sido desenvolvdida pelo nosso grupo de pesquisa. Desenvolvemos o
% metamodelo de PEWS e fizemos o mapeamento do n\'ivel PIM para PSM ($R_{39}$).
% Como a metodologia proposta é realmente desacoplada de qualquer linguagem, é
% possível gerar código para WS-BPEL, XAML e outras linguagem de composição de
% serviços, basta apenas a descrição do meta-modelo e o as regras de mapeamento
% (transformações entre os modelos). ($R_{37}$)
% 
% \bigskip
% \bigskip
% 
% Todas as transformações foram descritas em linguagem natural, visual e em
% ATL, no entanto as transformações em ATL mas não foram incluídas na manuscrito
% tese pelo fato de já terem sido descritas em linguagem natural. Como existe mais
% de uma linguagem para transformação, como o QVT e ATL, preferimos omitir estas
% transformação para o leitor da tese. Os exemplos das transformação
% em ATL apresentados no capítulo de embiente da metodologia são apenas para
% apresentar a estrutura geral de ATL e as principais transformações. 
% 
% No entanto, como forma de agregar valor ao texto da tese, iremos acrescentar em
% forma de apêndice da tese, as transformações descritas em ATL. ($R_{40}$)
% 
% 
% \bigskip
% \bigskip
%  
% Os requisitos de ambiente são: a ferramenta Eclipse Modelling (versão Galilleo
% ou superior) e todos os plugins proposto pela motodologia, os editores \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
% $\pi$-SerciveComposition} e \textit{$\pi$-PEWS}, além dos
% plugins de transformação. Uma vez que o ambiente é proposto no
% contexto da ferramenta Eclipse, os requisitos de ambiente necessários
% são os mesmos requisitados pela ferramenta Eclipse. ($R_{41}$)
% 
% \bigskip
% \bigskip
% 
% As visões propostas da metodologia separam os conceitos de serviço, negócio e
% políticas, como forma de classificar estes elementos/conceitos. Esta separação
% não implica em um efeito direto da modelagem ou transformação. Como o
% desenvolvimento usando $\pi$SOD-M integra os elementos de cada visão em todas as
% iterações e transformações, não vimos a necessidade de dividir o ambiente em
% visões, pelo fato das visões propostas serem uma forma de classificar conceitos
% importante para cada fase e transformação. ($R_{42}$)
% 
% \bigskip
% \bigskip
% 
% 
% Como sugerido, vamos usar o termo ``\textbf{\textit{Exemplos}}'' para os estudos
% de caso apresentados. Do mesmo modo, em vez de ``\ textit{Validação}'', usaremos
% o termo `` \textbf{\textit{Avaliação}}'' , no capítulo 5, como uma forma de
% melhor representar o que foi feito. ($R_{43}$)
% 
% \bigskip
% \bigskip
% 
% 
% No que diz respeito aos trabalhos futuros, estes foram organizados em três
% grandes áreas: Validação, Desenvolvimento e Atividades de Pesquisa.
% 
% No que diz respeito a validação, é nosso objetivo fazer uma análise mais
% quantitativa da metodologia. Esta análise irá verificar a quantidade de código
% gerado, e como esse código pode reduzir o tempo ou custo de desenvolvimento.
% Compararemos nosso método com abordagens de desenvolvimento de aplicação
% orientadas a serviços que gerem uma especificação da aplicação. Nosos objetivo é
% comparar o tipo de especificação gerada, e o que temos de diferente que
% justifique o uso da nossa metodologia. Os resultados serão submetidos para
% publicação de um journal internacional, mostrando as vantagens de se utilizar
% $\pi$SOD-M.
% 
% É nosso interesse também analisar e descrever possíveis linhas de produto de
% software para aplicações que sejam baseadas em requisitos não-funcionais, e como
% estas linhas de produto podem ser geradas a partir da nossa metodologia
% proposta. Uma outra área interessante no contexto de linhas de produto, é
% verificar a variabilidade dos requisitos não-funcionais propostos pela
% metodologia para aplicações orientadas a serviços.
% 
% Em relação ao desenvolvimento, seria interessante ter um ambiente completamente
% integrado com a linguagem $\pi$-PEWS e seu ambiente de execução. Dessa forma
% seria possível verificar se o código da especificação gerada tem alguma
% inconsistência, e verificar a sua corretude em runtime. Uma outra tarefa
% importante a ser relaizada em trabalhos futuros é o desenvolvimento de um
% ambiente completamente visual para a modelagem da aplicação, em todos os níveis
% propostos por $\pi$SOD-M.
% 
% Em relações a atividades de pesquisa, é importante que se formalise os modelos e
% suas regras de transformação de forma que possamos garantir formalmente a
% consistência dos modelos propostos e de suas regras de transformação. Um outro
% ponto importante é a definição de metamodelos de linguagens de composição de
% serviços e o mapeamento do nível PIM de $\pi$-ServiceComposition para a nova
% linguagem. ($R_{45}$)
% 
% \bigskip
%  
 


\bibliography{respostas}
\bibliographystyle{plain}

\end{document}
